This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Media delivery streaming solutions are mainly based on protocols such as Real time streaming Protocol (RTSP) as defined in the IETF RFC 2326, Microsoft Media Server (MMS) proprietary protocol from Microsoft or Real Time Messaging Protocol (RTMP) proprietary protocol from Adobe Systems.
Streaming techniques based on the HTTP protocol have emerged, to allow delivery of content over the Internet. These techniques allow a client device to receive video in the form of small successive small segments, called chunk, and being a few seconds long. Each segment is requested through the HTTP protocol and may exist in different variants, allowing the client device to choose at any time an appropriate bit-rate matching the network and its own constraints. Different bit rates correspond to different quality levels of the delivered content. As soon as the network bandwidth measured by the client device decreases, it requests chunks which are less restrictive with respect to network bandwidth requirement. When the network bandwidth measured by the client device increases, it requests chunks which are more restrictive with respect to network bandwidth requirement.
The available chunks are generally listed in a playlist generated and provided by the streaming server. The playlist can point to other playlists such as one per type of format. Playlists describe the chunk content, such as the codec or the required bandwidth for downloading it, and the way to request them. The playlist format can be the one described in the document “HTTP Live Streaming draft, pantos, http-live-streaming, 06”, extended with codec information to describe the various SVC layers.
Various HTTP streaming techniques are available. Apple HTTP Live Streaming (HLS) was published as a draft RFC, and is used mainly on Apple devices. Microsoft Smooth Streaming is part of the Microsoft Silverlight platform, and specifications are publicly available. Adobe Open Source Media Framework (OSMF) is close to the Microsoft solution. 3GPP has released specifications for a Packet Switched Streaming (PSS) system; An MPEG working group was also created around the definition of Dynamic Adaptive Streaming over HTTP (DASH). The benefit of using the HTTP protocol in these streaming solutions is its capability to cross over NAT and firewall seamlessly. These HTTP streaming technologies provide a way to compensate erratic network behavior regarding available bandwidth by continuously and gracefully upgrading or downgrading the video quality in order to fit with the bandwidth constraint.
In general HTTP streaming techniques are based on the same concept. They vary in the playlist file formats, the meta-data provided to describe the content options (bitrate, image dimensions, frame rate . . . ), the organisation of the available representations of the content in segments, in the codecs supported, and in the content protection technologies.
When a client device wants to play some audio/video content, it first has to get a file describing how this specific content can be obtained.
This is done through HTTP by getting some ‘file’ from an URL. This file basically lists the available representations of the content (in terms of bitrate and other properties) and for each one the URLs that enable loading the content segments for each time slice. For example for a Video on Demand content the entire description of the movie is provided, while for live broadcast content the description covers only a short period of time and needs to be reloaded periodically to discover the new items when time passes.
Depending on its capabilities and the knowledge it has from the network environment, the client device selects some representation (typically based on its bit-rate) and loads the first segment(s) of content. It buffers a few segments to be able to cope with network impediments. Then the content from each received segments are played one after the other. At the same time, the client device measures the reception rate and may decide to go to higher or lower bitrate. In such case, it just requests the next segment(s) from another representation. Every HTTP streaming system is such that it is possible for the client to keep a continuous playing while going from a segment in some bitrate to the ‘next’ segment in another bitrate. This way when traffic on the network introduces variations on the rate at which the content is received, the client can react by selecting segments with a bitrate that allows maintaining the client buffer filling to a secure level. Indeed the client usually tries to reach the highest possible bitrate to provide the better viewing quality, and to stay at a level where the rendering does not suffer from late reception of data causing macro-blocks or picture freezes.
In a residential network multiple client devices may carry out HTTP streaming simultaneously. If the bandwidth available on the local network or on the broadband network is not sufficient to support the whole traffic, the client devices compete to obtain their share of available bandwidth. The HTTP streaming algorithms independently run in each device and fail to provide an optimal share of the bandwidth. The following situations may occur. The bandwidth share may be unfair, as one of the video streams uses a high constant bitrate, while another one stays at a low bitrate. Or, oscillations may occur where each device alternatively use high and low bitrate. Sometimes the devices may simultaneously over-react to network conditions they judge unfriendly, resulting in the selection of a very low bit rate for each devices and a large waste of bandwidth. It may occur even when enough bandwidth is available; the TCP mechanisms underlying the HTTP protocol may suffer from the implicit competition of packets reception for each stream, and this produces the same results of either stable unfair situations or permanent oscillations. Such behaviour has a direct impact on the quality of experience for the end user, since the displayed video quality is linked to the used bitrate.